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REMARKS 

Reconsideration and allowance of the present application are respectfully 
requested. Claims 1-57 are currently pending in this application. 

/ Regarding the 35 U.S.C. § 112, First Paragraph Rejection 

Claims 1-30 and 48-51 were rejected under 35 U.S.C. § 112, first paragraph, as 

failing to comply with the enablement requirement. The Applicant respectfully traverses 

this rejection for the following reasons. 

The basis for the § 112, first paragraph, rejection is set forth in the following 

excerpt from page 4, paragraph No. 5 of the Office Action: 

The Examiner submits that the specification and claims go into great detail on the technical 
aspects of the invention. But the Examiner strongly believes that the invention cannot be 
enabled because the Examiner cannot ascertain what the invention is attempting to 
accomplish. The specification refers to various modules, which are swapped out to adapt the 
architecture to different domauis. [page 6] The Examiner requests that Applicant clearly 
cite where in the specification these various modules are defmed and what they actually 
accomplish. The Examiner sees that Applicant refers to the use of this architecture in various 
domains, and gives examples of such. The Examiner is unclear how, if at all, the invention 
can be implemented to actually work in said various domains. The Examiner understands 
that Applicant wishes to receive all possible breadth of claim coverage. In this case, the 
Applicant has attempted to describe vaguely a multiple of uses for the invention with a very 
clear technical description of the underlying subject matter. Unfortunately this combination 
has made it very difficult to actually implement the invention because there is no hint of how 
to implement the technical disclosure. A broader, over simplified analogy could be made to 
a person who has being [sic] given a detailed schematic of a telephone wiring closet without 
saying why it is there, what the telephone wiring closet actually is, or how it can be used to 
connect telephones so people can talk to each other over them. That person would then be 
able to read and understand the schematic, but would suffer an unreasonable burden in 
attempting to grasp what the intention is of the device described in the schematic and then 
once the intention was discovered would suffer yet another unreasonable burden in actually 



Lee d haVes. pllc 



18 



Serial No. 09/845,737 
Response Dated 9/12/2005 

deciding how the invention could be applied to various environments and implementing the 
invention to fit that inferred application. 

Thus, part of the rejection is based on the Examiner's perception that the application fails 
to teach how to use the invention - e.g., because the "Examiner cannot ascertain what the 
invention is attempting to accomplish." Another part of the rejection is based on the 
Examiner's assertion that the application fails to disclose how to make the invention - 
e.g., because the "Examiner is unclear how, if at all, the invention can be implemented to 
actually work in said various domains." The Applicant respectfully disagrees with the 
Patent Office's position for the reasons which follow. (At the outset, it should be noted 
that the following comments regarding the present specification are made to fully address 
the 35 U.S.C. § 112 rejection by demonstrating exemplary and non-limiting support for 
the claimed invention in the specification; but the comments should not be construed as 
limiting the scope of the invention as defined by the claims.) 

As set forth in MPEP § 2164.01, the overarching question in any § 112, first 
paragraph, analysis pertaining to enablement is whether the disclosure, when filed, 
contains sufficient information to enable one skilled in the pertinent art to make and use 
the claimed invention without undue experimentation. As to the question of "what the 
invention is attempting accomplish," the present specification is abundantly clear. While 
the invention does not address a "univocal" need, and therefore does not provide a 
"uni vocal" solution, one prominent goal of the subject matter described in the 
specification is to provide a server architecture that can accommodate modification in an 
efficient and flexible manner. 

Consider the problem addressed on page 1 of the specification. As indicated 
there, "source code is typically developed specifically for the domain of one computer 
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application." Since "the source code is developed specifically for each domain, the 
components of one computer application developed specifically for one domain might 
not be reusable for another computer application under development for another domain." 
As a further result, "because of the inability to reuse high-level components for multiple 
computer applications across diverse domains, the cost of developing a computer 
application can be quite high. In addition, because the components are new, their 
reliability is often improven." 

As set forth in the Summary section on pages 3 and 4, the subject matter disclosed 
in the present application addresses at least the above-identified problem through the use 
of a multi-layer server architecture. One exemplary benefit of the multi-layer 
architecture is set forth in page 4, lines 6-10: 

Any one of the layers may be removed, modified, or updated without impacting other layers. 
This allows the architecture to adapt easily to many different problem domains, to support 
many different types of client devices, to accommodate many different users in different 
regions and cultures of the world, and to interface with many diverse resources. 

Further discussion regarding the flexibility of the architecture can be found at least on 
page 6, lines 5-21, and on page 9, lines 11-21 of the specification. 

Thus, in answer to the Office Action's question of "what does the invention 
accomplish," the Applicant submits that one exemplary and non-limiting objective of the 
subject matter described in the present application is to provide a modular architecture 
that readily allows logic to be swapped in and out, thus expediting software development. 
The specification is abundantly clear on this issue. 

The Office Action's telephone wiring closet analogy addresses the "use" 
component of the enablement question in a different maimer by implying that the 
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specification fails to inform a practitioner in the relevant art how to actually use the 
multi-layer architecture in a concrete context. Again, this position is misplaced because 
the specification is abundantly clear regarding the manner in which the invention can be 
used. Consider, for example, the exemplary and non-limiting application shown in Fig. 
1. Fig. 1 shows a network system 100 in which the tiered software architecture may be 
implemented. The system 100 includes multiple clients 102(1), 102(2), 102(3), 
102(N) that submit requests via one or more networks 104 to an application server system 
106. Upon receiving the requests, the server system 106 processes the requests and 
returns replies to the clients 102 over the network(s) 104. In some situations, the server 
system 106 may access one or more resources 108(1), 108(2), 108(M) to assist in 
preparing the replies. Simply put, in one exemplary and non-limiting implementation, 
the multi-layer architecture can be employed to field user queries in an online maimer. 
This pertains to a "real world" application, steering one skilled in the art to one 
exemplary practical application of the concepts described in the presentation application. 

Now advancing to the question of how to make the invention, the invention, of 
course, is defined by the claims. Consider claim 1, which recites, inter alia, the elements 
of a multi-layer application that includes a problem-solving logic layer, an execution 
environment layer, an interface layer, and a presentation layer. The specification sets 
forth (with reference to Fig. 2) an architecture having a hierarchy of modules, including a 
business logic layer 204, an execution environment 202, various interface layers (e.g., 
206, 208, etc.), a presentation layer 212, and so forth. The architecture shown in Fig. 2 is 
described at least on page 8, line 20 to page 15, line 26 of the specification. Fig. 3 
illustrates one exemplary manner of operation of architecture shown in Fig. 2. The 
procedure shown in Fig. 3 is described at least on page 16, line 1 to page 19, line 2 of the 
specification. 
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In further regard to the question of how to make the invention, the Office Action 
questions how "the invention can be implemented to actually work in said various 
domains." The specification thoroughly describes one exemplary and non-limiting 
application of the architecture to the field of asset management. Note, for instance, page 
19, line 5 to page 33, line 1 of the specification. (As to this matter, also note that the 
claims are not presently directed to any particular business domain per se, thus reducing 
the need to exhaustively describe many different business domains. In other words, the 
subject matter described in the specification is directed to an architecture which can 
accommodate different business models, rather than the composition of business-specific 
models per se,) 

For the above reasons, the specification satisfies 35 U.S.C. § 112, first paragraph, 
by explaining how to make and use the invention, without requiring the exercise of undue 
experimentation. Accordingly, the Applicant respectfully requests the Patent Office to 
withdraw the 35 U.S.C. § 1 12, first paragraph, rejection. 

In any event, if the rejection is repeated in any way, the Applicant respectfully 
requests the Examiner to more carefully set forth a factual basis that explains why it is 
believed that the specification is non-enabling. This is required by MPEP § 2164.04: 

In order to make a rejection, the examiner has the initial burden to establish a reasonable 
basis to question the enablement provided for the claimed invention. In re Wright, 999 F.2d 
1557, 1562, 27 USPQ2d 1510, 1513 (Fed. Cir. 1993) (examiner must provide a reasonable 
explanation as to why the scope of protection provided by a claim is not adequately enabled 
by the disclosure). A specification disclosure which contains a teaching of the manner and 
process of making and using an invention in terms which correspond in scope to those used 
in describing and defining the subject matter sought to be patented must be taken as being in 
compliance with the enablement requirement of 35 U.S.C. 1 12, first paragraph, unless there 
is a reason to doubt the objective truth of the statements contained therein which must be 
relied on for enabling support. Assuming that sufficient reason for such doubt exists, a 
rejection for failure to teach how to make and/or use will be proper on that basis. In re 
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Marzocchi, 439 F.2d 220, 224, 169 USPQ 367, 370 (CCPA 1971). As stated by the court, "it 
is incumbent upon the Patent Office, whenever a rejection on this basis is made, to explain 
why it doubts the truth or accuracy of any statement in a supporting disclosure and to back 
up assertions of its own with acceptable evidence or reasoning which is inconsistent with the 
contested statement. Otherwise, there would be no need for the applicant to go to the trouble 
and expense of supporting his presumptively accurate disclosure." 439 F.2d at 224, 169 
USPQ at 370. 

The rejection, as it stands, is based on broad generalities and analogies, which do not 
address any particular issues of perceived technical deficiencies. Moreover, the rejection 
is prefaced by an indication that the Examiner "strongly believes" that the application is 
non-enabling. But the MPEP cautions that, "The examiner should never make the 
determination [pertaining to Section 112, first paragraph, analysis] based on personal 
opinion. The determination should always be based on the weight of all the evidence" 
(emphasis in original). As it stands, the general nature of the of rejection fails to shift the 
burden of rebuttal to Applicant; more practically. Applicant is at a loss to determine how 
to rebut this rejection without simply repeating what is considered clearly disclosed in the 
specification in its present form. 

As a final point, the Applicant points out that this application is a member of a 
family of nine patent applications having the same filing date (April 30, 2001). These 
applications include Application Nos. 09/845,751, 09/845,752, 09/845,780, 09/847,035, 
09/847,037, 09/847,038, 09/847,063, and 9/847,067. These applications include similar 
terminology to the present application, and use the same introductory figures, such as the 
multi-layer architecture drawing shovra in Fig. 2 of the presentation application. As per 
the typical course, some of the Examiners handling this family of applications raised 
minor 35 U.S.C. 1 12, second paragraph, rejections. Further, the Applicant submitted one 
amendment in this family of applications which provoked a 35 U.S.C. § 112, first 
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paragraph, rejection. However, none of the Examiners have raised the kinds of global 35 
U.S.C. § 112, first paragraph, concerns identified in the present Office Action. This is 
highly significant, as it indicates that others were not similarly stymied by the kind of 
exposition provided by the present application. This observation at least has a bearing on 
how the present application would be interpreted by one skilled in the pertinent art. 

Again, the Patent Office is respectfully requested to withdraw the 35 U.S.C. § 
1 12, first paragraph, rejection. 

// Regarding the 35 U,S.C. § 112, Second Paragraph, Rejection 

Claims 1-30 and 48-51 were rejected under 35 U.S.C. § 1 12, second paragraph, as 
being indefinite for failing to particularly point out and distinctly claim the subject matter 
which applicant regards as the invention. The Applicant respectfully traverses this 
rejection for the following reasons. 

In Paragraph No. 8 of page 5, the Office Action states that the term "presentation 
tier" in claim 16 has insufficient antecedent basis. The present Response amends claim 
16 in a manner which is believed to clarify the antecedent basis of this term. 

In paragraph No. 9 of page 5, the Office Action states that the term "locale- 
sensitive content" in claim 29 has insufficient antecedent basis. In claim 29, the term 
"locale-sensitive content" is introduced in line 2 of that claim, and then is used again in 
line 5 (where it is properly prefaced by the article "the"). Therefore, the Applicant 
submits that this term has proper antecedent basis as used in this claim. As such, the 
Patent Office is respectfully requested to withdraw this portion of the § 112, second 
paragraph, rejection. 

Paragraph No. 10 broadly states that many terms used in the claims are indefinite. 
More specifically, the Office Action states that: 
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With regard to claims 1-53, Applicant has freely acted as his own lexicographer. Applicant 
has used multiple terms that are not well known in the art and the Examiner has not 
encountered satisfactory definitions for said terms within the specification or within the prior 
art, including muhiple technical and computer dictionaries, as to clear up this deficiency. . . 
.... The terms are indefinite because the specification does not clearly define the terms to 
the extent required by the Examiner in order to allow one or ordinary skill in the art to 
reasonable understand the specification and invention with ease and clarity. 

The Office Action also identifies no fewer than 42 terms that are beheved to be 
indefinite. And the Office Action quaUfies the list of 42 terms by stating that the list is 
only a representative list. 

The Office Action's legal reasoning is misplaced. Unique inventions are, by 
definition, new, thus sometimes warranting the use of terms that are not foimd in 
technical dictionaries. With respect to these terms, MPEP § 2173.05(a) states: 

New terms are often used when a new technology is in its infancy or is rapidly evolving. The 
requirements for clarity and precision must be balanced with the limitations of the language 
and the science. If the claims, read in light of the specification, reasonably apprise those 
skilled in the art both of the utilization and scope of the invention, and if the language is as 
precise as the subject matter permits, the statute (35 U.S.C. 1 12, second paragraph) demands 
no more. Shatterproof Glass Corp, v. Libbey Owens Ford Co., 758 F.2d 613, 225 USPQ 634 
(Fed. Cir. 1985) 

In the present case, Applicant has taken care to use terms in the specification and 
the claims which are, in themselves, inherently descriptive. Thus, many of the terms used 
in the claims should be clear based on the plain meaning of the terms alone. For 
example, the Examiner questions what the term "multi-layer application" means. A 
multi-layer application is an application having multiple layers. Insofar as the textual 
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portion of the specification consistently uses this term, and the drawing portion of the 
specification illustrates the concept of a multi-layer application (e.g., with reference to 
Fig. 2), then the specification satisfies 35 U.S.C. § 1 12, second paragraph. 

Moreover, many other terms identified in the Office Action are used in the claims 
in such a manner that, upon introduction of a term, the claim itself defines what is meant 
by the term. To take one example, the Office Action questions what is meant by 
"interfacing layer" in claim 1. Claim 1 recites "an interfacing layer to interface the 
problem-solving logic layer with one or more resources." Implicit in this recitation is the 
definition that the interfacing layer is a layer which interfaces the problem-solving logic 
layer with one or more resources. This is abundantly clear on its face and is consistent 
with the usage of this term in the specification. The law demands no more. The other 
terms identified in the Office Action can are considered definite for similar reasons. 

In general, the MPEP repeatedly stress that claim language must satisfy an 
examiner only to the extent of satisfying the law. As stated in MPEP § 2173.02: 

The examiner's focus during examination of claims for compliance with the requirement for 
defmiteness of 35 U.S.C. 112, second paragraph, is whether the claim meets the threshold 
requirements of clarity and precision, not whether more suitable language or modes of 
expression are available. When the examiner is satisfied that patentable subject matter is 
disclosed, and it is apparent to the examiner that the claims are directed to such patentable 
subject matter, he or she should allow claims which define the patentable subject matter with 
a reasonable degree of particularity and distinctness. Some latitude in the manner of 
expression and the aptness of terms should be permitted even though the claim language is 
not as precise as the examiner might desire. 

In making the 35 U.S.C. § 1 12, second paragraph, rejection, the Office Action states that 
the "specification does not clearly define the terms to the extent required by the Examiner 
in order to allow one of ordinary skill in the art to reasonably understand the specification 
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and invention with ease and clarity" (emphasis added). The Examiner is respectfully 
requested to solely apply the law without reference to personal preference, as required by 
the MPEP. When this is done, the Applicant submits that the claims will pass muster 
under 35 U.S.C. § 1 12, second paragraph. 

For the above-identified reasons, the Patent Office is respectfully requested to 
remove the 35 U.S.C. § 1 12, second paragraph, rejection. 

///. Regarding the Objections to the Drawings 

Paragraph No. 2 of the Office Action (on page 2) objects to the drawings. More 
specifically, this portion of the Office Action reads, in part: 

The drawings are objected to because, though the drawings are comprehensive in nature and 
cover multiple aspects of the invention, the drawings still fail to convey to one of ordinary 
skill in the art what exactly is being accomplished by the invention. The closest drawing that 
the Examiner feels is to showing the actual usage of the invention, which is still unclear, is 
Figure 20, which shows a login prompt on a web page and a human translator. Even with 
these two items present in Figure 20, and the descriptions given for this and all other 
submitted drawings, the Examiner is not assisted in graphing the invention at all based upon 
the currently submitted drawings. 

Again, the invention is defined by the claims. For example, claim 1 recites several 
layers. These layers find exemplary and non-limiting support in at least Fig. 2 of the 
present application (note for instance, the above discussion pertaining to the 35 U.S.C. § 
112, first paragraph rejection). Further, Fig. 3 describes one exemplary and non-limiting 
manner of operation of the architecture shown in Fig. 2. Further still. Fig. 1 describes 
one exemplary and non-limiting application of the invention to an online query-type 
system. Thus, even this collection of introductory figures satisfactorily addresses the 
questions raised in the Office Action. 
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Since the drawings clearly illustrate exemplary implementations of the invention, 
the Applicant submits that no drawing changes are warranted. And for this reason, the 
Applicant respectfully requests the Patent Office to withdraw the objection to the 
drawings. 

IV, Regarding the Request for a Substitute Specification 

In paragraph No. 3 on page 3 of the Office Action, the Patent Office requests the 
Applicant to submit a substitute specification pursuant to 37 CFR § 1.125(a). The Office 
Action states that a substitute specification is required in view of the alleged deficiencies 
noted in the 35 U.S.C. § 1 12 rejections. However, as per the arguments presented above, 
the Applicant submits that the application satisfies both the first and second paragraphs of 
35 U.S.C. § 112. Since the specification requires no changes, the Patent Office is 
respectfully requested to remove the requirement for a substitute specification. 

More generally, as indicated above, the Applicant urges the Examiner to remove 
personal preference from the Examiner's application of the law. The Office Action 
states: 

The Examiner is careful to inform Applicant that the specification is compliant with 37 CFR 
1.71 only to the extent to avoid making the specification incomprehensible. The Examiner 
contends that the specification, while not being incomprehensible per se, is still highly 
difficult to comprehend to one of ordinary skill in the art (emphasis in original). 

The Applicant submits that if the specification is not "incomprehensible per se,'' then it is 
comprehensible, and therefore satisfies the applicable statutes and rules. The fact that the 
subject matter may be considered "difficult" is not a relevant legal consideration. 
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K Regarding the 35 U.S,C §102 Rejection 

Claims 1-9, 12-16, 18-21, 23-24, and 48-51 were rejected under 35 U.S.C. § 
102(b) as being anticipated by an excerpt from a book entitled, "UNIX Network 
Programming," by W. Richard Stevens (referred to below as "Stevens"). Applicant 
respectfully traverses this rejection for the following reasons. The arguments presented 
to address the § 102 rejection are to be interpreted as representative rather than 
exhaustive. 

Stevens describes various features of UNIX technology. In pages 334-341, 
Stevens describes an Internet superserver. The Internet superserver uses a single daemon 
(inetd) to service multiple connection requests (where a "daemon" refers to a background 
program). When a request is received pertaining to a particular service, the inetd daemon 
"forks" to an appropriate child process. The child process handles the service request. In 
other portions, Stevens discusses a presentation layer (e.g., page 250). The presentation 
layer modifies the representation of data to facilitate its exchange. 

Stevens does not disclose or render obvious the invention recited in the claims. 
Consider claim 1 , as currently amended, and reproduced in its entirety below. 

1 . A server system comprising: 
one or more computers; and 

a multi-layer application executing on the computers to handle client requests 
submitted by various client devices, the muhi-layer application comprising: 

a problem-solving logic layer to process the client requests according to an 
associated problem domain, wherein the problem domain pertains to a particular category of 
service, the problem-solving logic layer containing one or more execution models to perform 
various sets of tasks when processing the client requests, the problem-solving logic layer 
producing replies to the client requests; 

an execution environment layer to receive the client requests and select an 
appropriate execution model in the problem-solving logic layer for processing the client 
requests; 
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an interfacing layer to interface the problem-solving logic layer with one or more 
resources so that the execution models may utilize the resources when processing the client 
requests; and 

a presentation layer to receive the replies produced by the problem-solving logic 
layer and to structure the replies in a manner that makes the replies presentable on the 
various client devices, 

wherein any of the layers may be changed without impacting other layers. 

For instance, Stevens does not disclose a multi-layer application that handles 
client requests submitted by various client devices, wherein the multi-layer application 
includes the claimed combination of an a problem-solving logic layer, an execution 
envirormient layer, an interfacing layer, and a presentation layer, wherein any of the 
layers may be changed without impacting other layers. 

The Office Action states (in paragraph No. 14) that Steven's inetd process meets 
the elements in claim 1 which call for a problem-solving logic layer, an execution 
environment layer, and an interfacing layer. However, there is nothing in Stevens that 
would lead one of ordinary skill in the art to interpret the various aspects of the inetd 
daemon as forming three distinct layers. And indeed, it remains unclear the maimer in 
which the Patent Office itself is interpreting the inetd daemon as forming three distinct 
layers. 

As to the presentation layer, the Office Action states that the presentation layer of 
the OSI model (shown on page 7 of Stevens) meets the "presentation layer" recited in 
claim 1. However, there is nothing in Stevens to suggest that the OSI presentation layer 
can be integrated with a problem-solving logic layer, an execution environment layer, and 
an interfacing layer in the manner recited in claim L Certainly, the OSI model itself 
(shovm on page 7 of Stevens) includes a different combination of layers than is recited in 
claim 1. 
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To further distinguish the claimed invention over Stevens, claim 1 has been 
amended to recite that "any of the layers may be changed without impacting other 
layers." Even if, assuming arguendo, that Stevens can be construed as including the four 
distinct layers recited in claim 1 , there is no disclosure in Stevens that any of these layers 
can be changed without impacting the others. 

For at least the above-defined reasons, the Applicant submits that Stevens fails to 
disclose or render obvious the subject matter recited in independent claim 1 . 

Now advancing to independent claim 48, this claim is reproduced in its entirety 

below: 

48. A method for processing client requests in a system, comprising: 

receiving requests from multiple clients, the requests being related to a business- 
related problem domain, wherein the business-related problem domain pertains to a 
particular category of business-related service; 

processing the requests within problem-solving logic to produce replies within the 
business-related problem domain, the processing comprising requesting data to be used in 
formulating the replies; 

retrieving the data from one or more external resources and mapping the data to a 
domain framework for the business-related problem domain, the domain framework being 
independent from the problem-solving logic; and 

interfacing the problem-solving logic to the domain framework to obtain the data 
for use in processing the request, 

wherein a new business-related problem domain can be exchanged for a previous 
business-related problem domain by replacing one or more components of the system, 
without having to reconstruct an entire application solution for the new business-related 
problem domain. 

Stevens does not disclose the above-described subject matter. For instance, 
Steven's UNIX daemons perform relatively low-level background processes. Nowhere 
does Stevens disclose that these daemons implement business-related problem domains. 
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or that a new business-related problem domain can be exchanged for a previous business- 
related problem domain by replacing one or more components of the system, without 
having to reconstruct an entire application solution for the new business-related problem 
domain. 

Further, Stevens does not disclose the operations of "retrieving the data from one 
or more external resources and mapping the data to a domain framework for the business- 
related problem domain, the domain framework being independent from the problem- 
solving logic," and "interfacing the problem-solving logic to the domain framework to 
obtain the data for use in processing the request." Portions such as Section 5.6.6 of 
Stevens (on page 250) disclose a process for converting from an abstract syntax to a 
transfer syntax. This functionality, however, does not meet the specific subject matter of 
claim 48, where data from one or more external resources is mapped to a domain 
framework for a business-related problem domain, and where the problem-solving logic 
is interfaced to the domain framework to obtain the data for use in processing the request. 

For at least the above-defined reasons, the Applicant submits that Stevens fails to 
disclose or render obvious the subject matter recited in independent claim 48. 

The remainder of the claims that are rejected under § 102 depend from either 
independent claim 1 or claim 48. These claims are allowable for at least for this reason. 
Moreover, these claims recite additional features which are not disclosed in (or rendered 
obvious by) Stevens. 

To cite just one example, dependent claim 20 recites: 

20. (Original) A server system as recited in claim 1, further comprising a constraint 
system to constrain operation of the multi-layer application according to multiple different 
constraints, the constraint system comprising a hierarchy of constraint layers, with each 
constraint layer containing a set of one or more constraints that customize operation of the 
muhi-layer application. 
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Stevens does not disclose or suggest a constraint system that constrains the operation of a 
multi-layer application, where the constraint system is comprised of a hierarchy of 
constraint layers. The Office Action identifies Steven's configuration file (disclosed on 
pages 335-336) as having a bearing on this feature. However, the configuration file 
merely specifies the services that the superserver is to listen for and what to do when a 
service request arrives. It does not comprise a hierarchy of constraints. A flat list of 
information is not a hierarchy. Nor does the information in the configuration file 
customize the operation of an application as claimed. 

As stated in MPEP § 2131, "A claim is anticipated only if each and every element 
as set forth in the claim is found, either expressly or inherently described, in a single prior 
art reference." Verdegaal Bros. v. Union Oil Co. of California, 2 USPQ2d 1051, 1053 
(Fed. Cir. 1987). Since Stevens does not disclose every element of the rejected claims - 
and indeed discloses a markedly different system than is recited in the rejected claims - 
Stevens does not anticipate any of the claims. 

For the above reasons, the Patent Office is respectfully requested to withdraw the 
rejection based on 35 U.S.C. § 102(b). 

VL Regarding the 35 U.S.C § 103 Rejections 

Claim 17 was rejected under 35 U.S.C. § 103 as being unpatentable over Stevens 
and the Patent Office's "Official Notice." Claims 22 was rejected under 35 U.S.C. § 103 
as being unpatentable over Stevens alone. Claims 10-11 were rejected under 35 U.S.C. § 
103 as being unpatentable over Stevens in view of an excerpt from a book entitled, 
"UNIX in a Nutshell," by Daniel Gilly (referred to below as "Gilly"). Claims 25-28 were 
rejected under 35 U.S.C. § 103 as being unpatentable over Stevens in view of an excerpt 
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from a book entitled, "UNIX Power Tools," by Jerry Peek et al. (referred to below as 
"Peek"). And claims 29-30 were rejected under 35 U.S.C. § 103 as being unpatentable 
over Stevens in view of an excerpt from a book entitled, "Creating Worldwide Software," 
by Bill Tuthill (referred to below as "Tuthill"). Applicants respectfully traverse each of 
these rejections for the following reasons. 

First, the claims rejected under § 103 (claims 10-11, 17, 22, and 25-30) ultimately 
depend from claim 1 . Since the secondary references (Gilly, Peek, and Tuthill) do not 
remedy the deficiencies noted above with respect to claim 1, then claims 10-11, 17, 22, 
and 25-30 are allowable for at least this reason. 

In addition, claims 10-11, 17, 22, and 25-30 recite additional features which are 
not disclosed in or rendered obvious by any combination of the applied art - Stevens, 
Gilly, Peek, and Tuthill. This statement will be demonstrated with respect to 
representative claims 10, 17, 22 and 25. As before, the arguments presented to address 
the § 103 rejection are to be interpreted as representative rather than exhaustive. 

Consider first dependent claim 10, which was rejected based on a combination of 
Stevens and Gilly. It recites: 

10. A server system as recited in claim 1, wherein the interfacing layer comprises: 
a data abstraction layer to obtain data from the resources and map the data into a 

domain framework that models information flow for a specific problem domain; and 

a data coordination layer that provides an interface for the problem-solving logic 

layer to access the domain framework of the data abstraction layer and obtain the data. 

Neither Stevens nor Gilly disclose an interfacing layer comprising a combination 
of a data abstraction layer and a data coordination layer as claimed. The Office Action 
cites pages 10-1 to 11-11 of Gilly as having a bearing on the subject matter recited in 
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claim 10. This portion of Gilly describes an editor referred to as "sed." While this editor 
can loosely be said to modify a file, this feature is not even remotely related to an 
interfacing layer that includes a data abstraction layer and a data coordination layer as 
claimed. 

Dependent claim 17, which was recited based on Stevens alone, recites: 

17. A server system as recited in claim 1, wherein the presentation layer comprises: 
a presentation module to determine how the replies will appear on the client devices 
to users; and 

a rendering module, separate from the presentation module, to determine how to 
render the replies on the client devices. 

Stevens does not disclose the subject matter recited in this claim. The Office 
Action addresses this claim by stating that page 250 of Stevens discloses a presentation 
module. As to the rendering module, the Office Action states that "Official Notice is 
taken that displaying information on a screen has been well known in the art for 
decades." While this statement, considered in a vacuum, is certainly true, it does not 
have bearing on the subject matter set forth in claim 17. Claim 17 states that the 
presentation layer (introduced in the context of the multi-layer application of claim 1) 
includes a presentation module and a rendering module. There is no indication in the 
applied references that it would have been known in the art to partition a presentation 
layer (in the context recited in claim 1) into the two modules recited in claim 17, where 
the modules have the specific roles set forth in that claim (e.g., determining how the 
relies will appear, and determining how to render the replies). The Applicant also 
pointedly traverses the Examiner's reliance on Official Notice because there is no support 
in the record for the conclusion that the subject matter recited in claim 17 is "old and well 
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known" in the context claimed. In accordance with MPEP § 2144.035 the Patent Office is 
requested to cite a reference in support of its position. 

Consider next dependent claim 22, which was also rejected under § 103 based on 
Stevens alone. It recites in full: 

22. A server system as recited in claim 21, wherein the hierarchy of constraints 
comprises constraints selected from a group of constraints comprising: 

legally mandated constraints to constrain operation of the multi-layer application 
according to legal principles; 

company-mandated constraints to constrain operation of the multi-layer application 
according to preferences of a company that operates the application; 

customer constraints to constrain operation of the multi-layer application according 
to preferences of customers; 

cultural constraints to constrain operation of the muhi-layer application according to 
cultural aspects; and 

end user constraints to constrain operation of the multi-layer application according 
to preferences of an end user. 

Stevens nowhere discloses or even hints at a constraint hierarchy, so Stevens likewise 
fails to disclose the specific constraint layers recited in claim 22, comprising legally 
mandated constraints, company-mandated constraints, customer constraints, cultural 
constraints, and end user constraints. In Paragraph No. 35, the Office Action states that 
Stevens has "shown the use of constraints [parameters, arguments] in defining the use 
and limits of a program." The Office Action further states that it "would be obvious to 
one of ordinary skill in the art to apply a plethora of types of constraints to the Stevens 
description to allow for specialized operation according to the user and system specific 
needs." However, the information in Steven's configuration file does not constitute 
constraints that customize an application. Nor does the information in the configuration 
file form a hierarchy. And finally, the Examiner's statement regarding the specific 
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constraints recited in claim 22 has absolutely no support in the art of record, especially in 
view of the fact that Steven's does not disclose any constraints in the context being 
claimed. The reasoning set forth in the rejection of claim 22 is derived from the present 
specification, not the prior art; this reasoning therefore reflects the use of impermissible 
hindsight. 

Consider next dependent claim 25, which was rejected by the combination of 
Stevens and Peek. Claim 25 reads as follows: 

25. A server system as recited in claim 1, wherein the presentation layer includes a 
form processor to generate a data input form for the multi-layer application by automatically 
adding, to a form definition that defines the data input form, validation code to validate 
subsequent inputs to one or more fields of the data input form. 

Neither Stevens nor Peek disclose the above-described subject matter. The Office Action 
cites pages 875-879 of Peek as having a bearing on this claim. That portion describes 
inter alia a shell script for filling in forms. But this subject matter has no relationship to 
what is claimed other than its mention of the word "form." For instance, neither Stevens 
nor Peek, whether considered alone or in combination, disclose "automatically adding, to 
a form definition that defines the data input form, validation code to validate subsequent 
inputs to one or more fields of the data input form." Generally, the Office Action 
characterizes claims 25-28 as a "method for handling data forms." However, closer 
examination of these claims reveals that they recite much more functionality than merely 
handling forms. 

For the above reasons, the Patent Office is respectfully requested to withdraw the 
rejections based on 35 U.S.C. § 103. As stated in MPEP § 2143.01, to establish prima 
facie obviousness of a claimed invention, all the claim limitations must be taught or 
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suggested by the prior art. In re Royka, 490 F.2d 981, 180 USPQ 580 (CCPA 1974). As 
indicated above, all of the elements in the claims are not met by the cited references, even 
if, assuming arguendo, these references can be combined together in the manner set forth 
in the Office Action. 

VIL Regarding the Double Patenting Rejection 

Claims 1-30 and 48-51 were provisionally rejected under the judicially created 
doctrine of obviousness-type double patenting as allegedly being unpatentable over 
copending Application Nos. 09/845,734, 09/845,757, 09/68 1 ,567, 09/845,75 1 , 
09/845,752, 09/845,780, 09/847,035, 09/847,037, 09/847,038, 09/847,063, and 
09/847,067. Applicant respectfully traverses this rejection for the following reasons. 

In Paragraph No. 43, the Office Action sets forth the basis for the double 
patenting rejection as follows: 

Although the conflicting claims are not identical they are not patentably distinct from each 
other because the instant application could be made from a combination of the copending 
applications. Applicant has filed for twelve patents on April 30, 2001. The instant 
application seems to be, based upon the Examiner's best understanding of the instant 
application and all copending applications, a combination of all eleven copending 
applications. The majority of the copending applications have appeared in the instant 
application as depending claims. 

As stated in MPEP § 804, obviousness-type double patenting is based on a 
consideration of claims in the present application vis-a-vis the allegedly conflicting 
claims in the copending application(s) and/or patents. More specifically MPEP § 804 
states: 

Any obviousness-type double patenting rejection should make clear: 



UE & HAVES. PLLC 



38 



Serial No. 09/845,737 
Response Dated 9/12/2005 

(A) The differences between the inventions defined by the conflicting claims - a 
claim in the patent compared to a claim in the application; and 

(B) The reasons why a person of ordinary skill in the art would conclude that the 
invention defined in the claim in issue is an obvious variation of the invention 
defined in a claim in the patent. 

The MPEP also explicitly counsels against using the specification of the conflicting 
application(s) and/or patent(s) in making an obvious-type double patenting rejection, as 
follows: "When considering whether the invention defined in a claim of an application is 
an obvious variation of the invention defined in the claim of a patent, the disclosure of 
the patent may not be used as prior art." 

The Office Action's arguments fail to set forth any considerations that are 
relevant to a rejection under the doctrine of obviousness-type double patent rejection. 
Even if it is agreed that the application's detailed description combines subject matter 
from one or more of the above-identified applications, this is not determinative of 
whether the claims of the present application are obvious over the claims of the identified 
copending applications. The Office Action's rejection provides no detailed claim 
analysis, and thus fails to set forth a prima facie case of obviousness-type double 
patenting in the present application. 

Further, even if the claims of the applications are considered, there is no basis for 
a rejection under the doctrine of obviousness-type double patenting. The focus of the 
present claims, in one instance, is a server system having a multilayer application. 
Certain dependent claims in the present application recite "sub-features" which receive 
more extensive treatment in the claim sections of other respective copending applications. 
Nevertheless, there is no showing in the Office Action that the claims of the present 
application are obvious variants of the claims in the copending applications. 
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On this topic, it is pointed out that the Patent Office thought it appropriate to 
restrict the subject matter of the present appUcation into plural groups of claims. The 
restriction was issued under the rationale that these different claims recite 
subcombinations that are useable together. The Patent Office is requested to justify why 
it is appropriate to divide the subject matter in the present application into plural 
applications, yet it is not appropriate for the Applicant to pro-actively assist the Patent 
Office by dividing patentably distinct ideas into plural applications. The Patent Office's 
stance in making the restriction is inconsistent with its stance in rejecting the claims 
under the doctrine of obviousness-type double patenting. 

For the above-described reasons, the Applicant requests the Patent Office to 
remove the obviousness-type double patenting rejection. Alternatively, if the Patent 
Office repeats this rejection, it is respectfully requested to provide the analysis required 
by the MPEP, in which the claims of the present application are compared with the 
claims of the identified copending applications. 

As a footnote, the Applicant points out that the present application is considered a 
member of an application family that includes Application Nos. 09/845,751, 09/845,752, 
09/845,780, 09/847,035, 09/847,037, 09/847,038, 09/847,063, and 9/847,067. The 
remaining three applications identified in the Office Action (09/845,734, 09/845,757, and 
09/681,567) are not part of this family. 

VIIL Regarding the Request for Information 

Pages 12 and 13 of the Office Action request the Applicant, under 37 CFR § 
1.105, to provide information that the Examiner deems necessary to the examination of 
this application. In response to this request, the Applicant provides the following 
information. 
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In Paragraph No. 47, the Office Action requests the Applicant to: "Please provide 
the title, citation and copy of each publication that any of the applicants relied upon to 
draft the claimed subject matter." Applicant states that no publications were used to draft 
the claimed subject matter. 

In Paragraph No. 48, the Office Action requests the Applicant to: "Please provide 
the names of any products or services that have incorporated the claimed subject matter, 
prior to the filing of the instant application." Applicant states that a program referred to 
as GEtheSource incorporated logic that is related to the subject matter described in the 
present application. GEtheSource is a v^eb-based asset management application 
developed for Global Electronics Solutions business of GE Commercial Equipment 
Finance (now GE Commercial Finance). The logic pertaining to the present application 
was deployed in GEtheSource prior to the filing date of the presentation application, but 
Mdthin the one year "grace period" permitted by 35 U.S.C. § 102(b). If the Examiner has 
any fiirther questions regarding the events surrounding the development of the present 
application, the Examiner is invited to contact the undersigned by telephone. 

On the topic of information disclosure, an Information Disclosure Statement 
accompanies this Response. This Information Disclosure Statement collects the 
publications cited in the above-identified copending applications (09/845,751, 
09/845,752, 09/845,780, 09/847,035, 09/847,037, 09/847,038, 09/847,063, and 
9/847,067). 

IX. Conclusion and Request for Examiner Interview 

The arguments presented above are not exhaustive; Applicant reserves the right to 
present additional arguments to fortify its position. Further, Applicant reserves the right 
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to challenge the alleged prior art status of one or more documents cited in the Office 
Action. 

All objections and rejections raised in the Office Action having been addressed, 
it is respectfully submitted that the present application is in condition for allowance and 
such allowance is respectfully solicited. 

In the event that there are any issues left unresolved by this Amendment, the 
Examiner is requested to contact the undersigned to schedule a personal interview prior 
to issuance of another Office Action. The undersigned can be reached at the number 
listed below. 



Respectfully Submitted, 



Dated: September 12, 2005 




David M. Himtley 
Reg. No. 40,309 
(509) 324-9256, ext. 248 
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